SPECIFICATION 

[Electronic Version 1 .2.8] 

Security Mechanist for Computer 
Processing Modules 

[h4] Background of the Invention 

foil Computer programs are currently made extensible and efficient by the use of adjunct 
lP 1 progL modules such as plug-ins and dynamic link libraries. Plug-ins are computer 

program modules which can alter the behavior of a computer program without changing 
L computer program itself. A common example of plug-ins are those associated with 
currently ubiquitous web browsers. Briefly, a web browser is a computer program by 
wSch fuser 'retrieves multimedia documents and information through ^Vff^ 
Internet known as the World Wide Web. Installation of plug-ins allow edification of 
he behavior of the web browser without re-installing or otherwise changing the computer 
n tactions of the web browser itself. One example of such extended functionality is he 
emnid display of images of the Tagged Image File Format (TIFF). Such functionality 
s not provided by some web browsers currently, but installation of certain plug-ins add 
hrtetionality To use the plug-in, applications such as web browsers are designed to 
look for installed plug-ins and, if installed, invoke execution of those plug-ins upon 
activation of a particular function or activity. 

[ P 21 Plug-ins can sometimes be implemented as dynamic link libraries. Dynamic link libraries 
lP Z M used for other purposes as well. A dynamic link library is a collection of program 
modules Ich are generally not loaded until invoked by another Vm^Mlo^ 
example will illustrate. Consider a web browser which provides a spell-checking 
capTbmty for forms data entry. A web browser is typically a I**^ 
such that a considerable amount of memory is used when the web browser is executing. 
A spell-checker can also be resource-intensive. By implementing the spell-checker as 
part of a dynamic link library, execution of the web browser does not irnmediate ly load 
tTspell-checker into memory. Accordingly, the resources required for the spell-checker 
Z not immediately consumed. Instead, the spell-checker is loaded for execution . only 
when 1 Ser requests a spell checking function of the web browser. Such allows the web 
browser to execute more efficiently when the spell-check function is not invoked. 

f D 31 For reasons pertaining both to extensibility and efficiency, adjunct program modules such 

[P 1 Lpu^ 7 
in the popularity of such adjunct program modules is the simplicity with which they are 
implemented. To facilitate the use of adjunct processing modules, such modules are 



adjunct program module. 

[p4 , ^^-^^^^^^^ 

example is illustrative. Cons.de. -that ^mputen e ^ m a 

songs in the ubiquitous and ^^"^S tether that the user has purehased and 
computer using an MP3 f^Tf^^Z^ format bu, wishes to play 
downloaded a number of songs in a secure, c Bf ( jogramcan 

those songs along with the other soags .n ^ *^P3 torma ^ ^ 

be augmented with a plug-.n adjunct P f when jested, can decode 

copy-protected -f-^ ™* fOT 

„ However,duetomeacces t i = 

decoding from the adjunct P»gram ™duk and^ tore rteto ^ ^ 

format. The resulting MP3 m us.' tot^ffle couM tav rf^ or ^ 

SctTtSSfi: ^st,::a^ture„ y ftheSure,copy, r o.ected 
format decoded by the adjunct program module. 

c'otrp^^ 

modules. 



[h5] Summary of the Invention 

, p71 ta accordance with the present inventior .an ^ 

lP certificate from a requesung program module to ^authenl ^ 

m0 dule as authorized to request t'~^^n ^m<:m received from 

[p81 ^einterfaceoftnea.unctpro^— J, ^jffiKSS£ 

requires an authonzafcon interface of te*^^J* progra m module can request 



the requester's authorization interface. 

[p91 Xta. are a number of ways in which th« , -1 — 

requesting program module is ^"^X ld feSo^ * that signature 

[p10l There.ived — on,^ 

requested processing. Theowj« ^determined time, and the adjunct 
^ C*™ «ted processing if the certificate has exp.red. 

[p11l 

srrsr^grScanhecon^ 

when the received certificate includes « 

permissions adds a significant degree of flextbtht, m the f««VP 
IX^louT^g — » me decoded, un-secured, tm-protected audro 



data stream. 



6,12, As mentioned above, the identity of the ^^^ ^ZX 
challenged. Tta* r^^^^^SS-. according ,0 the 

associated with the certificate. 

me tes, data as a and use by 

authority. 

6,141 individually, each of these individual security mechanisms car, be used by the adjunct 



program module to significantly deter unauthorized use of adjunct program module* . The 
described security mechanisms can also be combined to provide a tremendous deterrence 
to unauthorized use of adjunct program modules over conventional adjunct program 
module interfaces. 



[h6] Brief Description of the Drawings 

fp1 5] Figure 1 is a block diagram of an application and two program modules which use 
certificates to authorize processing in accordance with the present invention. 

[p16] Figure 2 is a block diagram of a computer system in which the application and adjunct 
program modules of Figure 1 execute. 

[p1 7] Figure 3 is a block diagram of a certificate of Figure 1 in greater detail. 

[p1 8] Figure 4 is a logic flow diagram of a secure adjunct program interface in accordance with 
the present invention. 

[p1 9] Figure 5 is a logic flow diagram of the certificate verification of Figure 4 in greater detail. 

[p201 Figures 6A-B are a logic flow diagrams of respective embodiments of a challenge- 
response authentication interface in accordance with the present invention. 



[hi] Detailed Description of the Invention 

fp21l In accordance with the present invention, a security protocol is implemented between an 
application 102 (Figure 1) and a component 104A and between component 104A and a 
component 104B. Components 104A-B are adjunct program modules which are loaded 
and executed separately from application 102 and from each other but execution of which 
can be requested for application 102 or other components. In this illustrative 
embodiment, components 104A-B are modules of one or more dynamic link libraries 
(DLLs) The very nature of adjunct program modules suggests that execution of adjunct 
program modules by other program modules is both easy and straight-forward^ However, 
because of security protocols described herein, adjunct program modules can be used to 
perform tasks in which security is required. 

[p22] Application 102 and components 104A-B are each all or part of one or more computer 
processes executing within computer system 200 (Figure 2). Computer system 200 
includes one or more processors 202 and a memory 204 which can include randomly 
accessible memory (RAM) and read-only memory (ROM) and can ^include generally any 
storage medium such as magnetic and/or optical disks. Memory 204 and processors 202 
interact with one another through an interconnect 206. 



f D231 A user interacts with computer system 200 through one or more input/output QjO) 
lP 1 devices 208 which can include, for example, a keyboard, an elec*onic 

tablet or similar locator device, an optical scanner, a printer, a CRT or LCD monitor, a 
ouTd card, a microphone, one or more loudspeakers, and/or a network access device 
through which computer system 200 can be connected to a computer 
facilitate understanding of the inter-operation of the elements of compute ' ^ 200 
according to this illustrative embodiment, the illustrative example of playback of secured 
and copy-protected audio data is continued. Under control of a user, e g through 
physical manipulation of one or more of I/O devices 208, application 102 and 
components 104 collectively decode the secured, copy-protected audio data to produce 
mw audio data for playback through one or more of I/O devices 208 such as a sound card 
and loudspeakers. While computer system 200 is shown to be a single computer system, 
it is appreciated that application 102 and/or one or more of components 104 can be 
distributed over multiple computer systems which are interconnected to perform the 
functions described herein. 

[ P 24] Furthering the illustrative example of decoding and playing back secured, copy-protected 
1 audio data, such decoding is performed by one of components 104, e.g., component 104B 
(Figure 1) To accomplish such decoding, application 102 requests execution ot 
component 104A which in turn requests execution of component 104B. In this 
illustrative example, component 104A verifies authorization of the user to access the 
secured audio data prior to requesting decoding of the secured audio data by component 
104B Since component 104B decodes secured audio data and returns the raw audio data 
in this illustrative example, it is desirable that component 104B ensures that such 
decoding is performed only for duly authorized requesters, e.g., component 104A and/or 
application 102. 

f D 251 As shown in Figure 1, component 104B includes substantive computer code 144B which, 
lP in this illustrative example, decodes secured, copy-protected audio data and produces raw 
audio data when executed. Substantive computer code 144B includes computer 
instructions and data which collectively specify the behavior of component 104B 
Component 1 04A includes substantive computer code 144A which is analogous to 
substantive computer code 144B of component 104B. Substantive : computer code 124 of 
application 102 is also analogous to substantive computer code 144A-B. Ot course, 
substantive computer code 124 and 144A can specify a different behavior than that 
specified by substantive computer code 144B. 

fp26] Application 102 includes interface references 120, each of which identifies an interface 
which in turn specifies a manner in which application 102 interacts with an adjunct 
program module such as component 104A. Component 104A includes ^ invocation 
interface 145A which specifies a manner in which execution of component 104A is 
invoked. To request processing by component 104A, application 102 must first acquire 
access to invocation interface 145A. Application 102 requests, and component 104A 
provides a reference to invocation interface 145A which application 102 stores in 



interface references 120 and subsequently uses to request processing from component 



104 A. 



[ D 271 Component 104A also includes one or more interface references 140A each of which 
identifies an interface which in turn specifies a manner by which component 1 04 A can 
invoke execution of other components such as component 104B. Component 104B 
includes invocation interface 145B and interface references HOB which are analogous to 
invocation interface 145A and interfaces 140A, respectively, of component 104A. 

r D 281 To facilitate the security protocol described herein, each application and component can 
include an authorization interface. For example, application 1 02 includes authorization 
interface 129 which specifies the manner in which another program module can request 
authentication of application 102. Components 104A-B similarly include authorization 
interfaces 149A-B, respectively. 

fp291 Application 102 also includes an authorization provider 128 which includes computer 
instructions and data which specify the behavior of application 102 when authentication 
is requested in accordance with authorization interface 129. Components 104A and 104B 
similarly include authorization providers 148A and 148B, respectively. 

[p301 To authenticate a requesting program module, an adjunct program module can request a 
certificate of the requesting program module. In response, the authorization provider of 
the requesting program module supplies a certificate of the requesting program module. 
For example, application 102 includes a certificate 122, component 104A includes a 
certificate 142A, and component 104B includes a certificate 142B. While each certificate 
is shown to be included within each application or component, each certificate can 
alternatively be stored in memory 204 (Figure 2) separately from the associated 
application or component of the certificate. For example, certificate 122 can be stored 
within memory 204 separately from application 102. Such facilitates replacement of 
expired certificates or replacement of a certificate with another, e.g., to change the 
permissions of the certificate. 

f p31 1 Certificates are well-known and are described herein for completeness. However, full 
appreciation of certificates requires a basic understanding of asymmetric encryption 
which is also well-known and which is also described herein for completeness. The 
simplest of encryption techniques uses the same key for encryption and decryption. 
Encryption scrambles data from its original, native form to a scrambled, apparently 
undecipherable form. Decryption recovers the original data from the scrambled 
apparently undecipherable form. Symmetric key encryption can be satisfactory for secure 
archival in which the person who is likely to want to decrypt the data is the same person 
who encrypted the data in the first place. However, when one party wishes to encrypt 
data for secure transport to another party, symmetric key encryption requires that the key 
is somehow transported as well, compromising security and/or representing a significant 
inconvenience. 



f D 321 Asymmetric key encryption uses pairs of reciprocal keys. The keys are reciprocal in that 
lP ] by one key of the pair can only be undone by decrypting using the other key of 

the pair. Asymmetric key encryption is sometimes referred to as public key encryption 
because one key of a pair of reciprocal keys is held in strict secrecy and pnvacy while the 
other key of the pair is distributed publicly within the system of intended use of the public 
key The system of intended use can be as large or larger than the Internet and can be as 
small as a single computer. Data can be encrypted for transport to a receiving party by 
encrypting the data using the public key of the receiving party. Thus, only the private key 
of the receiving party can decrypt the data. 

[p331 Public key encryption also permits cryptographic signatures of data. To sign a collection 
of data, a party uses its private key to encrypt the data or, alternatively, tc .form a hash of 
the data such that the data is still available in cleartext form without verification of the 
signature. The data can be decrypted - or alternatively the hash can be verified - using 
the public key of that party. Since the public key is widely and publicly distributed within 
the system of intended use, the data is not secure when encrypted in this manner 
However, successful decryption of the data using the party's public key verifies that it 
was encrypted by the party using its private key and therefore verifies the authenticity of 
the data as originating with the signing party. Such a cryptographic signature can be used 
to verify that noone has tampered with the data after the data was cryptographically 
signed. 

[p341 One issue with verifying cryptographic signatures is verification that a particular public 
key belongs to a particular party. For example, a cryptographic signature from a trusted 
party is only as reliable as the certainty that the public key used to verify the signature is 
ttuly from the trusted party and not some imposter. A certificate binds a public key to a 
particular party. Generally, a certificate includes a public key and data identifying the 
owner of the public key. The certificate is signed by a trusted certificate authority which 
is typically an organization that is widely trusted to issue certificates. The cryptographic 
signature of the certificate authority ensures that noone has tampered with the certificate 
after its issuance. 

[p35] Certificate 122 (Figure 1) is shown in greater detail in Figure 3 and is illustrative. 
Certificates 142A-B (Figure 1) are analogous to certificate 122 and the Rowing 
description of certificate 122 in the context of Figure 3 is equally applicable to certificates 
142A-B. 

[ P 36] Certificate 122 (Figure 3) includes a public key 302 and an owner field 304. Owner field 
304 stores data identifying application 102 (Figure 1) as the owner of certificate 22. 
Public key 302 (Figure 3) is a public key of application 102 (Figure 1) Certificate 
authority field 306 (Figure 3) stores data identifying the certificate authority which issued 
certificate 122. Expiration field 308 stores data specifying a time after which certificate 
122 is no longer valid. 

[p37] Certificate 122 includes a number of permissions 310. Each of permissions 310 includes 



data specifying one or more types of actions which are permitted for the owner of 
certificate 122 e.g., application 102 (Figure 1). Permissions 310 are used in a manner 
described more completely below to limit the types of actions adjunct program modules 

perform at the request of application 102. Certificate 122 is cryptographically Signed 
by the certificate authority to prevent tampering. 

r D 381 Logic flow diagrams 400A-B (Figure 4) illustrate an adjunct program module interface 
tP 1 wTenhancedlecurity in accordance with the present invention. Logic flow diagram 
400A illustrates processing by a requesting application or a requesting adjunct program 
module, and logic flow diagram 400B illustrates processing by an invoked adjunct 
program module. In particular, an invoked adjunct program module, e£, component 
?04BTncludes an authorization verifier, e.g., authorization verifier 147B, which verifies 
authority of the requesting program module prior to performing the requested processing. 
In the context of logic flow diagrams 400A-B, the requesting application or adjunct 
program module is sometimes referred to as the requester. In the illustrative example of 
Figure 1, the requester can be application 102 and the invoked adjunct program module 
can be component 104A. Alternatively, the requester can be component 104A and the 
invoked adjunct program module can be component 104B. 

f D 391 In step 402 (Figure 4), the requester invokes the invoked adjunct program module in a 

[P 1 c^nvliond^^^ The 
parameters required by the invoked adjunct program module are specified by the 
invocation interface of the invoked adjunct program module. In this illustrative example, 
component 104B (Figure 1) is the invoked adjunct program module and invocation 
interface 145B specifies the parameters required for proper execution of substantive 
computer code 144B. Each such required parameter is data to be supplied by the 
requester, e.g., component 104A in this illustrative example. 

r D 401 The required parameters can include the authorization interface of the requester, e.g., 
lP J autlorization interface 149A. The required parameters can also, or alternatively, require 
an authorization interface of a requester of the requester. In this illustrative example 
invocation interface 145B can require the authorization interface of application 102 e.g., 
authorization interface 129, in lieu of or in addition to the authorization interface of the 
requester, e.g., authorization interface 149A of component 104A. 

FD411 In step 452, component 104B (Figure 1) receives the parameters and authorization 
lP nterface. in step 454, authorization verifier 147B (Figure 1) of component 104B requests 
and receives the certificate of the requester, e.g., certificate 142A, using the received 
authorization interface. In step 404, the authorization provider of the requester e.g., 
authorization provider 148A, receives the request for the certificate and sends the 
certificate. 

[ P 42] In test step 456 (Figure 4), authorization verifier 147B (Figure 1) determines whether the 
certificate authorizes processing in a manner described more completely below. If so 
component 104B proceeds with processing according to substantive computer code 14413 



in step 458 (Figure 4). Conversely, if the certificate does not authorize processing, 
component 104B produces an error message as the results of processing in step 460. In 
step 462 component 104B sends the results, either from step 458 or from step 460, to the 
requester. In step 406, the requester receives the results from the invoked adjunct 
program module. 

[p431 As described above, authorization verifier 147B verifies that the received certificate 

authorizes processing in test step 456. Test step 456 is shown in greater detail as logic 
flow diagram 456 (Figure 5). In step 502, authorization verifier 147B (Figure 1) verifies 
the signature of the certificate authority of the received certificate. In this illustrative 
example, the certificate received by authorization verifier 147B in step 454 (Figure 4) is 
certificate 122 (Figures 1 and 3). In other examples, the received certificate can be 
certificate 142 A (Figure 1) or another certificate. 

[p44] The certificate authority of certificate 122 (Figure 3) is identified by certificate authority 
field 306 To verify the signature of certificate 122, authorization verifier 147B (Figure 
1) uses a certificate authority public key 141B. Since the public key is widely and 
publicly distributed within the system of intended use, application 102 and components 
104A-B all include copies of the public key of the certificate authority or otherwise have 
access to a copy. In test step 504 (Figure 5), authorization verifier 147B determines 
whether the signature of the certificate authority is verified. If so, processing transfers to 
test step 506. 

[p45] In test step 506, authorization verifier 147B (Figure 1) determines whether certificate 122 
has expired by reference to a date and time represented by expiration field 308 (Figure 3). 
If the certificate has not expired, processing transfers to step 508. 

[p461 In step 508, authorization verifier 147B challenges the requester to verify the identity of 
the requester. As described above, the requester can have directly or indirectly requested 
processing by component 104B. The manner in which the requester is challenged and 
responds is described more completely below. In test step 510, authorization verifier 
147B determines whether the requester responded properly to the challenge. If so, 
processing transfers to test step 512. 

[p47] In test step 512, authorization verifier 147B determines whether the certificate in question 
includes one or more required permissions. In particular, component 104B performs 
processing only when a certificate grants the direct or indirect requester permission for 
such processing. Thus, component 104B is configured to perform requested processing 
only when a supplied certificate includes one or more requisite permissions. 
Accordingly, authorization verifier 147B of component 104B, in test step 512, searches 
permissions 310 (Figure 3) for the one or more requisite permissions. 

[p48] If all requisite permissions are found in the supplied certificate, processing transfers to 
terminal step 514 in which authorization verifier 147B of component 104B determines 
that the supplied certificate authorizes processing at the request of the requester. 



Conversely if (i) one or more requisite permissions are not found in the supplied 
certificate (test step 512) or (ii) the requester responds improperly to the challenge (test ^ 
step 510) or (iii) the supplied certificate has expired (test step 506) or (iv) the certificate s 
signature by the certificate authority is not verified (test step 504), processing transfers to 
terminal step 516 in which authorization verifier 147B of component 104B determines 
that the supplied certificate does not authorize processing at the request of the requester. 

[p49] Thus, an attempt to request processing by component 104B from an ^authorized 

program module is prevented. Consider for example that component 104B decoded 
secure and copy-protected audio data for playback and produced therefrom 
uncompressed, cleartext, digital audio signals. Component 104B can require 
authentication of both component 104A as a direct requester and application 102 as an 
indirect requester. Any other module attempting to use component 104B to decode and 
decrypt such audio signals would have to produce a certificate identifying itself, having 
the proper permissions (test step 512), and signed by a certificate authority (test step 504). 
In addition, the imposter module would have to correctly respond to a challenge of the 
imposter's authority in steps 508-510. Each of these mechanisms provides security well 
beyond any security provided by conventional adjunct program modules. 

fp501 The challenge-response authentication of steps 508-510 is shown more completely as 
logic flow diagram 508 (Figure 6A) and processing by the requester in response to the 
challenge is illustrated by logic flow diagram 600. An alternative embodiment of step 
508 is shown as logic flow diagram 508B (Figure 6B) and is described more completely 
below. 

fp51] Processing according to logic flow diagram 508 (Figure 6A) begins with step 602 in 
which authorization verifier 147B of component 104B generates random or pseudo- 
random data. In step 604 (Figure 6A), authorization verifier 147B (Figure 1) sends the 
random data to the requester associated with the certificate in question. As described 
above the requester can be a direct requester such as component 104A or an indirect 
requester such as application 102. In this illustrative example, the challenged requester is 
component 104A. 

[p52] Component 104A includes challenge code 143A which includes computer instructions 
and data which collectively specify a behavior of authorization provider 148A of 
component 104A in response to a challenge such as that initiated by component 104B in 
step 604 (Figure 6A). Processing in accordance with challenge code 143A is illustrated 
by logic flow diagram 600. In step 652, authorization provider 148 A receives the random 
data In step 654, authorization provider 148 A cryptographically signs the random data 
using private key 146A (Figure 1). Private key 146A is the reciprocal key to the public 
key included in certificate 142A. In step 656, authorization provider 148A sends the 
signed random data, or alternatively a hash signature of the random data, to component 
104B as the response to the challenge. 

[p53] In step 606, authorization verifier 147B receives the decrypted random data. In test step 



608, authorization verifier 147B verifies the signature of the random data using the public 
key of the certificate in question. If the received signature is verified, authorization 
verifier 147B establishes that the requester responded properly to the challenge, thus 
proving that the requester has the private key associated with the supplied certificate. 
Conversely, if the received signature is not verified, authorization verifier 147B 
establishes that the requester did not respond properly to the challenge and therefore may 
not have the associated private key. Thus, as a precondition for processing as requested, 
component 104B can require both authentication in the form of a certificate and evidence 
that the requester has the associated private key in the requester's possession. Such 
represents a high level of security against unauthorized requests for processing by adjunct 
program modules. 

[p54] An alternative challenge-response protocol is shown in logic flow diagrams 600B (Figure 
6B) and 508B in which processing begins with step 622. In step 622, authorization 
verifier 147B generates random or pseudo-random data. In step 624, authorization 
verifier 147B encrypts the random data using the public key of the certificate. In step 
626, authorization verifier 147B (Figure 1) sends the encrypted random data to the 
requester associated with the certificate in question. 

[p55] In step 672, authorization provider 148 A (Figure 1) receives the encrypted random data. 
In step 674 (Figure 6B), authorization provider 148 A (Figure 1) decrypts the encrypted 
random data using private key 146A. Successful decryption of the encrypted random data 
establishes possession of private key 146 A and therefore establishes proper ownership of 
certificate 142A received by component 104B. In step 676 (Figure 6B), authorization 
provider 148A (Figure 1) sends the decrypted random data to component 104B as the 
response to the challenge. 

[p56] In step 628 (Figure 6B), authorization verifier 147B (Figure 1) receives the decrypted 

random data. In test step 610, component 104B compares the received decrypted random 
data with the original random data. If the received decrypted random data matches the 
original random data, component 104B establishes that the requester responded properly 
to the challenge. Conversely, if the received decrypted random data is different from the 
original random data, component 1 04B establishes that the requester did not respond 
properly to the challenge. 

[p57] A number of advantages are realized by interposing an authorization interface between 
the invoked adjunct program module and the requesting program module. One such 
advantage is a significant degree of flexibility in implementing the security protocol 
described herein. The following example is illustrative. Consider that application 102 
invokes component 104B directly and that later component 104A is interposed between 
application 102 and component 104B. Such is possible with very little modification, if 
any, to application and component 104B. Component 104B can still require certificate 
122 of application 102 and can require proper challenge-response from application 102. 

[p58] Specifically, application 102 invokes component 104A and provides authorization 



interface 129. Component 104A subsequently invokes component 104B and provides 
authorization interface 149 A. Without modification, authorization verifier 147B expects 
to receive certificate 122 of application 102 and preconditions proper response to a 
challenge by application 102 in the manner described above. Accordingly, authorization 
verifier 147B requests a certificate using authorization interface 149 A. 

[p59] Authorization provider 148 A receives the request for a certificate. However, since 
component 104B is constructed with the knowledge that component 104B expects to 
interact directly with application 102, authorization provider 148 A requests and receives 
certificate 122 from application 102 using authorization interface 129 and passes 
certificate 122 to authorization verifier 147B. Accordingly, authorization verifier 147B 
receives the expected certificate. 

[p60] Similarly, authorization provider 148 A can forward authority challenges from 

authorization verifier 147B to authorization provider 128 and can forward associated 
responses from authorization provider 128 to authorization verifier 147B and thus 
preserve the authentication verification between application 102 and component 104B. 

[p61 ] The flexibility afforded by the use of authorization protocols enables countless other 

possibilities. For example, authorization provider 148 A can require authority verification 
by authorization verifier 147 A and authorization provider 128 as a prerequisite to 
providing a required certificate to authorization verifier 147B. In addition, authorization 
provider 148 A can include multiple certificates, each with different permissions and can 
provide a specific one of the certificates depending upon various circumstances. 

[p62] Another advantage of using authorization interfaces is that the behavior of an 

authorization provider can be subsequently modified without requiring modification of 
other elements of a particular program module. 

[p63] Yet another advantage of using authorization interfaces is that authorization code can be 
supplied separately from the substantive computer code of a particular program module. 
For example, one entity can provide authorization provider 148 A and authorization 
interface 149 A as object code to be linked into component 104 A by a second, separate 
entity. Thus, the first-mentioned entity can provide the public key infrastructure of 
authorization provider 148 A without disclosing the specific details of the public key 
infrastructure, thus preserving the security provided by the public key infrastructure. 
Simultaneously, the second entity can construct authorization verifier 147A to request 
certificates and challenge authorization of requesting program modules using 
authorization interfaces of those program modules without requiring knowledge of the 
specific details of the public key infrastructure. Such allows the security protocol 
described herein without disclosing the specific details to those who use the security 
protocol. 

[p64] The above description is illustrative only and is not limiting. Instead, the present 
invention is defined solely by the following claims. 



